Three healthsystem tests failing:

1. test_which_hsi_can_run
2. test_rescaling_capabilities_based_on_squeeze_factors
3. test_run_in_mode_1_with_almost_no_capacity

The tests 2 & 3 look safe to remove. They're using the capabilities_coefficient to scale capabilities down to 0, leading to high squeeze factor, and therefore testing squeeze factors indirectly. They're both testing mode 1, so I think both these tests can be removed because we won't have squeeze factors for mode 1.

However the first test, test_which_hsi_can_run looks a bit more complex because it's testing the actual/funded staffing. This did have an impact on the squeeze factor in mode 1 via current_capabilities. With no squeeze factor for mode 1, is it correct to remove this test for mode 1? I thought yes, but then see that you're also testing actual/funded staffing in mode 0.

(FAO @marghe-molaro)

Hi @tamuri,

test_run_in_mode_1_with_almost_no_capacity: can safely go, because as you said it has become redundant.

test_which_hsi_can_run: the reason for testing mode 0/1 under actual vs funded scenarios is to test how these modes handle a complete lack of capabilities from certain officers.
In actual, there are certain districts where certain officers are not available, hence their capabilities are zero; in funded, all cadres have at least some capabilities present, meaning all capabilities > 0. Mode 0 and 1 handle this differently, as shown here:

test_rescaling_capabilities_based_on_squeeze_factors: this needs to be kept as it is quite key to our "mature" mode 2 functioning, which relies on the rescaling of capabilities - where however this should now be based_on_load rather than based_on_squeeze_factors, where load is defined in the image below.
Load is lighter to compute because the total footprint of appts per cadre needs to be computed only once at the end of the day, rather than being recalculated/corrected continuously. Notice also that the only time we need this calculated dynamically is prior to the transition to mode 2, so we could have something like if sim.date.year == year_of_trans - 1: calculate load. In all other cases, it doesn't need to be dynamically computed as it can be computed in post processing.

Please let me know if anything is unclear, happy to discuss over a call if easier.

Thanks! I think I understand. Perhaps we do some pair programming to box this off. Feels like it should be fairly straightforward.

Hi @tamuri, just checking the best way to go about this - should I work on the tamuri/1661-remove-squeeze-factors branch directly, branch-off it, or create a completely new branch from master?

And reminding us of things I need to add:

• [] Function to dynamically compute and store 'load' of officers if rescaling to actual capabilities;
• [] Replace squeeze factor logic to handle 'missing officer case' in mode 1

Thanks, Margherita. If this branch helps at all, feel free to continue on it. However works best for you.

Hi @tamuri,

Above issues now addressed in #1689.

A few additional comments:

• Luckily, the concept of “load” was already introduced in the PR that implemented capability rescaling. In test_rescaling_capabilities_based_on_squeeze_factors, the only change I introduced therefore is how the success of rescaling is assessed: instead of checking whether the squeeze factors of HSIs have decreased, we now check whether the load on officers has decreased.

• For determining whether HSIs can proceed in mode 1, I replaced the previous check for infinite squeeze with a check that all required officers have non-zero capabilities. This may be a bit computationally cumbersome (although it should still be cheaper than relying on squeeze); I wonder if it would be best to compile a list of all HSIs types that can go ahead in each facility whenever daily_capabilities are updated, and then use that as a look up table instead...let me know what you think.

Closing in favour of #1781

Closing in favour of #1781